feat: Add UEFI HTTP boot support#98
Conversation
…action for UEFI loader
…network parameters
|
测试环境: loongarch pc机 
|
…iagnostics for UEFI loader
|
在loongarch-pc机器中传输启动内核成功： 
|
…ing to UEFI loader
![mai-team-app[bot]](https://avatars.githubusercontent.com/u/34859362?s=60&v=4){kind=small}
There was a problem hiding this comment.
PR #98 Review: feat: Add UEFI HTTP Boot support
变更概览
本 PR 为 ostool 添加了 UEFI HTTP Boot 支持，涉及 45 个文件，新增约 9500 行代码。变更覆盖以下几个层次：
- 新增
httpbootcrate：no_std的 UEFI manifest 解析核心库，包含手工 JSON 解析器和 device path URI 提取 - UEFI 应用入口：通过
efi_main实现 UEFI HTTP 协议引导流程（manifest 下载 → kernel 下载 → ExitBootServices → 跳转入口） - loongarch64-uefi-loader：原生 C 加载器（TCP4/TLS/HTTP/manifest 支持）
- ostool-server 端：新增 HTTP Boot 文件服务、HTTPS 静态文件服务器、ProxyDHCP 服务
- ostool CLI 端：新增
run httpboot子命令，完整的上传→引导→会话管理流程
测例变更分析
本 PR 对现有测试行为的影响：
session_ws_lifecycle.rs：最小改动，仅添加了http_boot和proxy_dhcp配置字段到测试用的ServerConfig。这两个字段使用#[serde(default)]，不影响已有的解析行为。config.rs测试：新增board_config_round_trip_supports_uefi_http_boot测试，验证新增的UefiHttpProfile序列化/反序列化。已有测试中新增了http_boot.root_dir相关断言，不影响已有行为。router.rs测试：新增http_boot_upload_manifest_and_public_download_use_board_current_path和http_boot_upload_rejects_non_uefi_http_board两个集成测试，验证 HTTP Boot 文件上传/下载流程。已有测试中BootConfigmatch 分支新增UefiHttp处理（panic），不影响已有逻辑。client.rs测试：新增parse_uefi_http_boot_profile测试。已有BootConfigmatch 分支新增UefiHttp处理。httpbootcrate：12 个单元测试全部通过（本地验证），覆盖 manifest 解析、地址解析、device path URI 提取、边界条件等。http_boot/files.rs：2 个单元测试，验证文件存储路径和路径校验。
结论：对现有行为没有破坏性影响。 所有改动都使用 #[serde(default)] 保证向后兼容，已有 match 分支仅补充了新的变体处理（panic），不改变已有分支行为。
代码质量评价
优点：
httpbootcrate 的no_stdJSON 解析器实现精简且健壮，错误处理清晰- UEFI ABI 绑定手工编写，结构体布局明确
- 文件上传使用原子 rename（先写临时文件再 rename），保证一致性
- 路径校验完善，防止目录遍历攻击
- HTTPS 静态文件服务器实现简洁，读取请求行和头部有长度限制
- ProxyDHCP 实现完整，包含 arch 匹配、MAC 过滤、IP 校验
建议改进（非阻塞）：
httpboot/src/uefi/http.rs:283—poll_http_token使用 busy-wait 轮询（循环 10万次），建议添加注释说明 UEFI 环境下没有更好的等待机制httpboot/src/uefi/console.rs:10—write_console固定 192 元素 UTF-16 缓冲区，长消息会被静默截断，建议在截断时至少输出...提示ostool-server/src/api/router.rs:76— 短路径/B.EFI、/manifest.json、/kernel.bin使用硬编码 board_id"l"，建议在文档中说明用途ostool-server/src/config.rs:74—HttpBootHttpsConfig默认证书路径，如用户启用 HTTPS 但未创建证书，错误信息较底层，建议增加友好提示ostool-server/src/api/router.rs:1190—put_http_boot_file中读取两次config，两次读取之间配置可能已变，建议复用
CI 状态
所有 CI 检查均已通过：check (stable, x86_64-unknown-linux-gnu) ✅、Release-plz PR ✅、build ✅、deploy ✅
总结
功能完整、测试覆盖良好、对现有行为无破坏性影响。CI 全绿，12 个 httpboot 单元测试本地验证全部通过。建议合并。
Powered by glm-5.1
…ate and arch validation
There was a problem hiding this comment.
PR #98 代码审查：feat: Add UEFI HTTP boot support
变更概览
本 PR 为 ostool 添加了完整的 UEFI HTTP Boot 支持，涉及 46 个文件，约 9500 行新增代码。变更涵盖以下层次：
httpbootcrate：no_std的 UEFI manifest 解析核心库，手工 JSON 解析器 + device path URI 提取，12 个单元测试全部覆盖httpbootUEFI 应用：通过efi_main实现完整的 HTTP Boot 流程（manifest 下载 → kernel 分块下载 → ExitBootServices → 跳转入口），支持boot-jumpfeature gate 控制loongarch64-uefi-loader：原生 C 风格 UEFI 加载器，支持 TCP4 直连 + TLS 加密 + HTTP fallback + 网络 warmup 重试- ostool-server：新增 HTTP Boot 文件服务（上传/下载）、HTTPS 静态文件服务器、ProxyDHCP 服务
- ostool CLI：新增
run httpboot子命令，完整上传 → 引导 → 会话管理流程
代码质量评价
优点：
httpbootcrate 的no_stdJSON 解析器实现精简，错误处理清晰，12 个单元测试覆盖了所有关键路径- 文件上传使用原子 rename（先写临时文件再 rename），保证一致性
- 路径校验完善，
normalize_relative_path和normalize_board_id防止目录遍历攻击 - HTTPS 静态文件服务器实现简洁，请求行和头部有长度限制（8192 bytes）
- ProxyDHCP 实现完整，包含 arch 匹配、MAC 过滤、IP 校验、vendor class 检测
#[serde(default)]保证新配置字段向后兼容- 架构分离良好：httpboot 独立 no_std 库、server 端 http_boot/files + http_boot/https + proxy_dhcp 模块化
发现的问题
1. 🟡 loongarch64-uefi-loader 中存在硬编码 IP 地址
src/flow.rs:48 和 src/flow.rs:63 中硬编码了 10.3.10.229:3443 和 10.3.10.229 作为 fallback 主机地址。更关键的是 src/tcp4.rs:456 中 HTTP Host 头部硬编码为 10.3.10.229：
// src/tcp4.rs:456
const VERSION_HOST: &[u8] = b" HTTP/1.1\r\nHost: 10.3.10.229\r\nConnection: ";这意味着无论实际服务器地址是什么，HTTP GET 请求都会发送 Host: 10.3.10.229，在多站点部署场景下会导致请求路由错误。建议从 manifest URL 中解析 host 并传入 build_http_get_request。
2. 🟡 cargo fmt 检查不通过
ostool/src/run/httpboot.rs 第 413 行有尾部空白：
UefiBootArch::Other => "other",
}
-
}
3. 🟢 短路径路由硬编码 board_id
/B.EFI、/manifest.json、/kernel.bin 路由使用硬编码 board_id "l"：
async fn get_http_boot_short_loader(State(state): State<AppState>) -> Result<Response, ApiError> {
read_http_boot_current_file(&state, "l", "BOOTLOONGARCH64.EFI").await
}这看起来是 LoongArch 开发调试用的快捷路由。建议添加注释说明用途，或在配置中暴露 board_id。
4. 🟢 Uboot 验证逻辑被移除
本 PR 移除了 UbootProfile::validate()、BoardConfig::validate()、ensure_ipv4()、UbootNetworkMode 以及 normalize_boot_config 中的 uboot 网络验证逻辑。虽然这些改动被 CI 覆盖，但它们的功能影响范围超出了 HTTP Boot 特性。如果这是有意为之的重构，建议在 PR 描述中说明。
5. 🟢 write_console 缓冲区截断无提示
httpboot/src/uefi/console.rs:10 中 write_console 使用 192 元素 UTF-16 缓冲区，长消息会被静默截断。建议在截断时至少输出 ... 提示。
测试覆盖
httpbootcrate：12 个单元测试（manifest 解析、地址解析、device path URI、边界条件）http_boot/files.rs：2 个测试（文件存储路径、路径校验）router.rs：新增 HTTP Boot 上传/下载集成测试config.rs：新增UefiHttpProfile序列化/反序列化测试- 已有测试中
BootConfig::UefiHttp分支添加 panic 占位，不影响已有行为
CI 状态
CI 检查已全部通过（check、build、deploy、Release-plz）。
总结
功能完整、架构清晰、测试覆盖良好。对现有行为无破坏性影响（#[serde(default)] 保证向后兼容）。主要建议：修复 loongarch64-uefi-loader 中的硬编码 IP 地址问题以及 cargo fmt 格式问题。建议合并。
Powered by mimo-v2.5-pro
There was a problem hiding this comment.
PR #98 审查：feat: Add UEFI HTTP boot support
变更概览
本 PR 为 ostool 添加了完整的 UEFI HTTP Boot 支持，涉及 47 个文件，新增 9616 行代码。变更覆盖：
httpbootcrate：no_stdUEFI manifest 解析核心库，12 个单元测试覆盖全面httpbootUEFI 应用：完整的 HTTP Boot 流程（manifest 下载 → kernel 分块下载 → ExitBootServices → 跳转入口）loongarch64-uefi-loader：原生 C 风格 UEFI 加载器，支持 TCP4 + TLS + HTTP- ostool-server：HTTP Boot 文件服务、HTTPS 静态服务器、ProxyDHCP 服务
- ostool CLI：
run httpboot子命令
CI 状态
所有 CI 检查已通过（check、build、deploy、Release-plz）✅
代码质量评价
优点：
httpbootcrate 的no_stdJSON 解析器精简健壮，错误处理清晰，测试覆盖全面- 文件上传使用原子 rename（先写临时文件再 rename），保证一致性
- 路径校验完善（
normalize_relative_path+normalize_board_id），防止目录遍历攻击 - ProxyDHCP 实现完整，包含 arch 匹配、MAC 过滤、vendor class 检测
- 新配置字段使用
#[serde(default)]，保证向后兼容性 - 已在 loongarch 实机上验证成功启动内核
发现的问题
⚠️ 1. 破坏性变更：移除了 Uboot 网络配置字段
本 PR 从 UbootProfile 中移除了以下字段：
kernel_load_addr、fit_load_addr、bootm_addrnetwork_mode、board_ip、server_ip、netmask、gatewayip- 同时删除了
UbootNetworkMode枚举、UbootProfile::validate()、BoardConfig::validate()和ensure_ipv4()函数
由于 UbootProfile 标记了 #[serde(deny_unknown_fields)]，任何包含上述字段的现有 board 配置文件将解析失败。例如：
[boot]
kind = "uboot"
network_mode = "dhcp" # 将导致反序列化错误网络配置似乎已迁移至 server 级别的 TftpNetworkConfig，但此变更属于破坏性变更，建议：
- 在 PR 描述或 commit 中说明此变更
- 考虑提供一个迁移指南或兼容性说明
- 或者至少在 release notes 中标注
⚠️ 2. cargo fmt 格式问题
ostool/src/run/httpboot.rs:413 — 存在尾部空白字符，cargo fmt --check 报错：
Diff in /workspace/repo/ostool/src/run/httpboot.rs:413:
UefiBootArch::Other => "other",
}
-
}
⚠️ 3. loongarch64-uefi-loader 硬编码 IP 地址
flow.rs:48,63 和 tcp4.rs:456 硬编码了 10.3.10.229：
// tcp4.rs:456
const VERSION_HOST: &[u8] = b" HTTP/1.1\r\nHost: 10.3.10.229\r\nConnection: ";这意味着无论实际服务器地址是什么，HTTP 请求的 Host 头部始终为 10.3.10.229。这显然是开发/测试环境的残留。建议从 manifest URL 中解析 host 并传入 build_http_get_request。
建议（非阻塞）：
- 硬编码 board_id：
/B.EFI、/manifest.json、/kernel.bin路由使用硬编码 board_id"l"，建议添加注释说明用途 - 控制台缓冲区截断：
httpboot/src/uefi/console.rs中write_console在 192 字符处静默截断消息，建议至少输出...提示 - TOCTOU：
put_http_boot_file函数两次读取state.config，两次读取之间配置可能已变，建议合并为一次读取
总结
功能完整、测试覆盖良好、CI 全绿、已在 loongarch 实机上验证成功。主要关注点是 Uboot 网络字段的破坏性移除和 cargo fmt 格式问题。建议合并且在上线前确认 Uboot 配置兼容性。
Powered by deepseek-v4-pro
There was a problem hiding this comment.
PR #98 代码审查：feat: Add UEFI HTTP boot support
变更概览
本 PR 为 ostool 添加了完整的 UEFI HTTP Boot 支持，涉及 113 个文件，新增约 10000 行代码。变更涵盖以下层次：
httpbootcrate：no_std的 UEFI manifest 解析核心库，手工 JSON 解析器 + device path URI 提取，12 个单元测试全部通过httpbootUEFI 应用：完整的 HTTP Boot 流程（manifest 下载 → kernel 分块下载 → ExitBootServices → 跳转入口），支持 HTTP Range 请求loongarch64-uefi-loader：原生 UEFI 加载器，支持 TCP4 直连 + TLS 加密 + HTTP fallback + 网络 warmup 重试- ostool-server：新增 HTTP Boot 文件服务（上传/下载）、HTTPS 静态文件服务器、ProxyDHCP 服务
- ostool CLI：新增
run httpboot子命令，完整上传 → 引导 → 会话管理流程
验证结果
| 检查项 | 结果 |
|---|---|
cargo fmt --check |
✅ 通过 |
httpboot crate 单元测试 |
✅ 12/12 通过 |
完整构建（cargo test --no-run） |
ostool-server 构建 |
| 与 main 的合并 |
代码质量评价
优点：
httpbootcrate 的no_stdJSON 解析器实现精简健壮，边界条件处理完善（空 body、过大 body、非 UTF-8、转义字符串等均有测试覆盖）- 文件上传使用原子 rename（先写临时文件再 rename），保证一致性
- 路径校验完善（
normalize_relative_path+normalize_board_id），防止目录遍历攻击 - ProxyDHCP 实现完整，包含 arch 匹配（X86_64/Aarch64/Loongarch64）、MAC 过滤、vendor class 检测、IP 校验
- HTTPS 静态文件服务器实现简洁，请求行和头部有长度限制（8192 bytes）
- 新配置字段使用
#[serde(default)]，保证向后兼容性 - HTTP Range 请求支持，实现 kernel 分块下载
- 架构分离良好：httpboot 独立 no_std 库、server 端模块化清晰
发现的问题
⚠️ 1. 破坏性变更：UbootProfile 字段移除
本 PR 从 UbootProfile 中移除了以下字段：kernel_load_addr、fit_load_addr、bootm_addr、network_mode、board_ip、server_ip、netmask、gatewayip。同时删除了 UbootNetworkMode 枚举、UbootProfile::validate()、BoardConfig::validate() 和 ensure_ipv4() 函数。
由于 UbootProfile 标记了 #[serde(deny_unknown_fields)]，任何包含上述字段的现有 board 配置文件将直接解析失败。网络配置似乎已迁移至 server 级别的 TftpNetworkConfig，但此变更属于破坏性变更，建议在 PR 描述或 release notes 中说明迁移路径。
⚠️ 2. loongarch64-uefi-loader 硬编码 IP 地址
三处硬编码 10.3.10.229：
flow.rs:48— fallback 主机10.3.10.229:3443flow.rs:63— fallback 主机10.3.10.229tcp4.rs:456— HTTPHost头部固定为Host: 10.3.10.229，无论实际服务器地址是什么
tcp4.rs:456 的硬编码最为关键：
const VERSION_HOST: &[u8] = b" HTTP/1.1\r\nHost: 10.3.10.229\r\nConnection: ";这意味着 HTTP GET 请求始终发送 Host: 10.3.10.229，在非目标环境中会导致请求路由错误。建议从 manifest URL 中解析 host 并传入 build_http_get_request。flow.rs 中的 fallback 地址在开发阶段可以接受，但建议后续改为可配置。
🟢 3. 短路由硬编码 board_id
/B.EFI、/manifest.json、/kernel.bin 路由使用硬编码 board_id "l"（LoongArch 开发调试用快捷路由）。建议添加注释说明用途。
🟢 4. write_console 缓冲区截断无提示
httpboot/src/uefi/console.rs 中 write_console 使用 192 元素 UTF-16 缓冲区，长消息会被静默截断。建议在截断时输出 ... 提示。
🟢 5. put_http_boot_file 中双重读取配置
router.rs 中 put_http_boot_file 函数两次读取 state.config，两次读取之间配置可能已变。建议复用单次读取结果。
总结
功能完整、架构清晰、测试覆盖良好。httpboot crate 的 12 个单元测试全部通过，cargo fmt --check 通过。主要关注点是 Uboot 网络字段的破坏性移除（需在文档中说明迁移路径）和 loongarch64-uefi-loader 中的硬编码 IP 地址（特别是 HTTP Host 头部）。
当前 PR 与 main 存在合并冲突（6 个文件），需要作者 rebase 后再合并。
建议合并（待解决合并冲突后）。
Powered by Mai
Powered by mimo-v2.5-pro
There was a problem hiding this comment.
PR #98 代码审查：feat: Add UEFI HTTP boot support
变更概览
本 PR 为 ostool 添加了完整的 UEFI HTTP Boot 支持，涉及 112 个文件，新增约 11400 行代码。变更涵盖以下层次：
httpbootcrate：no_std的 UEFI manifest 解析核心库，手工 JSON 解析器 + device path URI 提取，12 个单元测试全部通过 ✅httpbootUEFI 应用：完整的 HTTP Boot 流程（manifest 下载 → kernel 分块下载 → ExitBootServices → 跳转入口），支持 HTTP Range 请求loongarch64-uefi-loader：原生 UEFI 加载器，支持 TCP4 直连 + TLS 加密 + HTTP fallback + 网络 warmup 重试- ostool-server：新增 HTTP Boot 文件服务（上传/下载）、HTTPS 静态文件服务器、ProxyDHCP 服务
- ostool CLI：新增
run httpboot子命令，完整上传 → 引导 → 会话管理流程
验证结果
| 检查项 | 结果 |
|---|---|
cargo fmt --check |
✅ 通过 |
httpboot crate 单元测试 |
✅ 12/12 通过 |
| 与 main 合并 | ❌ 4 个文件存在冲突 |
代码质量评价
优点：
httpbootcrate 的no_stdJSON 解析器实现精简健壮，边界条件处理完善- 文件上传使用原子 rename（先写临时文件再 rename），保证一致性
- 路径校验完善（
normalize_relative_path+normalize_board_id），防止目录遍历攻击 - ProxyDHCP 实现完整，包含 arch 匹配（X86_64/Aarch64/Loongarch64）、MAC 过滤、vendor class 检测
- HTTPS 静态文件服务器实现简洁，请求行和头部有长度限制（8192 bytes）
- 新配置字段使用
#[serde(default)]，保证向后兼容性 - HTTP Range 请求支持，实现 kernel 分块下载
- 架构分离良好：httpboot 独立 no_std 库、server 端模块化清晰
需要解决的问题
⚠️ 1. 合并冲突
当前 PR 与 main 分支存在 4 个文件的合并冲突：
ostool-server/src/api/router.rsostool-server/src/config.rsostool-server/src/lib.rsostool-server/tests/session_ws_lifecycle.rs
需要 rebase 或 merge main 后才能合并。
⚠️ 2. UbootProfile 破坏性变更
本 PR 从 UbootProfile（标记了 #[serde(deny_unknown_fields)]）中移除了以下字段：
kernel_load_addr、fit_load_addr、bootm_addrnetwork_mode、board_ip、server_ip、netmask、gatewayip
同时删除了 UbootNetworkMode 枚举和 UbootProfile::validate() 函数。
由于 deny_unknown_fields 的存在，任何包含上述字段的现有 board 配置文件将直接解析失败。建议：
- 在 PR 描述或 release notes 中说明此破坏性变更
- 提供迁移指南（说明网络配置已迁移至 server 级别的
TftpNetworkConfig）
⚠️ 3. loongarch64-uefi-loader 硬编码 IP 地址
三处硬编码 10.3.10.229：
flow.rs:48— fallback 主机10.3.10.229:3443flow.rs:63— fallback 主机10.3.10.229tcp4.rs:456— HTTPHost头部固定为Host: 10.3.10.229
tcp4.rs:456 的硬编码最为关键：
const VERSION_HOST: &[u8] = b" HTTP/1.1\r\nHost: 10.3.10.229\r\nConnection: ";这意味着 HTTP GET 请求始终发送 Host: 10.3.10.229，在非目标环境中会导致请求路由错误。建议从 manifest URL 中解析 host 并传入 build_http_get_request。
🟢 4. 短路由硬编码 board_id
/B.EFI、/manifest.json、/kernel.bin 路由使用硬编码 board_id "l"（LoongArch 开发调试用快捷路由）。建议添加注释说明用途，或在配置中暴露 board_id。
🟢 5. write_console 缓冲区截断无提示
httpboot/src/uefi/console.rs 中 write_console 使用 192 元素 UTF-16 缓冲区，长消息会被静默截断。建议在截断时输出 ... 提示。由于同时输出到 COM1 串口，串口日志不受影响。
总结
功能完整、架构清晰、测试覆盖良好。httpboot crate 的 12 个单元测试全部通过，cargo fmt --check 通过。主要需要解决：
- 合并冲突（4 个文件）
- UbootProfile 破坏性变更需文档说明迁移路径
- loongarch64-uefi-loader 中的硬编码 IP（特别是 HTTP Host 头部）
建议合并且在上线前解决上述问题。
Powered by Mai
Powered by mimo-v2.5-pro
There was a problem hiding this comment.
PR #98 代码审查：feat: Add UEFI HTTP Boot support
变更概览
本 PR 为 ostool 添加完整的 UEFI HTTP Boot 支持，涉及 47 个文件，新增约 10163 行代码。变更涵盖：
httpbootcrate：no_stdUEFI manifest 解析核心库，手工 JSON 解析器 + device path URI 提取httpbootUEFI 应用：完整的 HTTP Boot 流程（manifest 下载 → kernel 分块下载 → ExitBootServices → 跳转入口）loongarch64-uefi-loader：原生 UEFI 加载器，支持 TCP4 直连 + TLS 加密 + HTTP fallback + 网络 warmup 重试- ostool-server：新增 HTTP Boot 文件服务、HTTPS 静态文件服务器、ProxyDHCP 服务
- ostool CLI：新增
run httpboot子命令
代码质量评价
优点：
httpbootcrate 的no_stdJSON 解析器实现精简健壮，错误处理清晰- 文件上传使用原子 rename（先写临时文件再 rename），保证一致性
- 路径校验完善（
normalize_relative_path+normalize_board_id），防止目录遍历攻击 - ProxyDHCP 实现完整，包含 arch 匹配、MAC 过滤、vendor class 检测
- HTTPS 静态文件服务器实现简洁，请求行和头部有长度限制
- 新配置字段使用
#[serde(default)]，保证向后兼容性 - 架构分离良好：httpboot 独立 no_std 库、server 端模块化清晰
ostool-server编译通过 ✅
需要修复的问题
🔴 1. 合并冲突
当前 PR 与 main 存在合并冲突（mergeable_state: dirty），无法直接合并。需要 rebase 或 merge main。
🔴 2. 测试编译失败
cargo test -p ostool-server 编译失败：
error: couldn't read `ostool-server/src/../../docs/examples/Asus-nuc15-x86_64-vmx.board.toml`: No such file or directory
--> ostool-server/src/config.rs:768:23
新增的测试 asus_nuc15_x86_64_vmx_example_board_config_parses 引用了 docs/examples/Asus-nuc15-x86_64-vmx.board.toml，但该文件未在 PR 中提交。需要添加此示例文件，或将测试改为不依赖外部文件。
🟡 3. loongarch64-uefi-loader 中硬编码 IP 地址
三处硬编码 10.3.10.229：
tcp4.rs:456— HTTPHost头部固定为Host: 10.3.10.229，无论实际服务器地址是什么flow.rs:48— fallback 主机10.3.10.229:3443flow.rs:63— fallback 主机10.3.10.229
tcp4.rs 中的问题最为关键：
const VERSION_HOST: &[u8] = b" HTTP/1.1\r\nHost: 10.3.10.229\r\nConnection: ";HTTP GET 请求始终发送 Host: 10.3.10.229，在非目标环境会导致请求路由错误。建议从 URL 中动态解析 host 并传入 build_http_get_request。
🟡 4. UbootProfile 破坏性变更
本 PR 从 UbootProfile 中移除了多个字段（kernel_load_addr、fit_load_addr、bootm_addr、network_mode、board_ip、server_ip、netmask、gatewayip）。由于 UbootProfile 标记了 #[serde(deny_unknown_fields)]，任何包含这些字段的现有 board 配置文件将直接解析失败。建议在 PR 描述中说明此变更并提供迁移指南。
建议（非阻塞）
/B.EFI、/manifest.json、/kernel.bin短路由使用硬编码 board_id"l"，建议添加注释说明用途write_console使用 192 元素 UTF-16 缓冲区，长消息会被静默截断，建议输出截断提示put_http_boot_file中两次读取state.config，两次读取之间配置可能已变，建议复用
总结
功能完整、架构清晰，整体代码质量良好。需要修复的关键问题：
- 解决合并冲突
- 补充缺失的示例文件或修复测试
- 修复
loongarch64-uefi-loader中的硬编码 IP 地址（特别是 HTTP Host 头部）
建议修复上述问题后合并。
Powered by mimo-v2.5-pro
1 participant
No description provided.